Interpretation of int (*a)[3]

Posted by kapuzineralex on Stack Overflow See other posts from Stack Overflow or by kapuzineralex
Published on 2010-02-12T08:12:28Z Indexed on 2010/04/20 21:23 UTC
Read the original article Hit count: 193

Filed under:
|
|
|

When working with arrays and pointers in C, one quickly discovers that they are by no means equivalent although it might seem so at a first glance. I know about the differences in L-values and R-values. Still, recently I tried to find out the type of a pointer that I could use in conjunction with a two-dimensional array, i.e.

int foo[2][3];
int (*a)[3] = foo;

However, I just can't find out how the compiler "understands" the type definition of a in spite of the regular operator precedence rules for * and []. If instead I were to use a typedef, the problem becomes significantly simpler:

int foo[2][3];
typedef int my_t[3];
my_t *a = foo;

At the bottom line, can someone answer me the questions as to how the term int (*a)[3] is read by the compiler? int a[3] is simple, int *a[3] is simple as well. But then, why is it not int *(a[3])?

EDIT: Of course, instead of "typecast" I meant "typedef" (it was just a typo).

© Stack Overflow or respective owner

Related posts about c

    Related posts about types